در صورت عدم موفقیت یک یا چند مرحله ، کار انجام شده توسط یک سری مراحل را انجام دهید ، که در کنار هم یک عملیات در نهایت سازگار را تعریف می کنند. عملیاتی که از مدل قوام نهایی پیروی می کنند ، معمولاً در برنامه های میزبان ابر که فرآیندهای پیچیده تجاری و گردش کار را اجرا می کنند ، یافت می شود.

زمینه و مشکل

برنامه های کاربردی در ابر اغلب داده ها را تغییر می دهند. این داده ها ممکن است در منابع داده های مختلفی که در مکان های مختلف جغرافیایی نگهداری می شوند پخش شود. برای جلوگیری از مشاجره و بهبود عملکرد در یک محیط توزیع شده ، یک برنامه نباید سعی در ایجاد قوام معامله ای قوی داشته باشد. در عوض ، برنامه باید قوام نهایی را پیاده سازی کند. در این مدل ، یک عملیات تجاری معمولی شامل یک سری مراحل جداگانه است. در حالی که این مراحل در حال انجام است ، ممکن است دید کلی از وضعیت سیستم متناقض باشد ، اما هنگامی که این عملیات به پایان رسید و تمام مراحل اجرا شده است ، سیستم باید دوباره سازگار شود.

آغازگر سازگاری داده اطلاعاتی را در مورد اینکه چرا معاملات توزیع شده به خوبی مقیاس نمی شوند ، و اصول مدل قوام نهایی ارائه می دهد.

یک چالش در مدل قوام نهایی این است که چگونه می توانید گامی را که شکست خورده است ، انجام دهیم. در این حالت ، ممکن است لازم باشد تمام کارهایی را که توسط مراحل قبلی در عملیات انجام شده است ، خنثیسازی کنیم. با این حال ، داده ها به سادگی نمی توانند به عقب برگردند زیرا سایر موارد همزمان برنامه ممکن است آن را تغییر داده باشد. حتی در مواردی که داده ها به صورت یک نمونه همزمان تغییر نکرده اند ، ممکن است یک قدم خنثیسازی به سادگی موضوع بازگرداندن وضعیت اصلی نباشد. ممکن است لازم باشد که قوانین مختلف تجاری را اعمال کنید (به وب سایت سفر که در بخش مثال شرح داده شده است مراجعه کنید).

اگر عملیاتی که سازگاری نهایی را پیاده سازی کند ، چندین فروشگاه داده ناهمگن را شامل می شود ، و قدم های آن در این عملیات به نوبه خود به بازدید از هر فروشگاه داده نیاز دارد. کار انجام شده در هر فروشگاه داده باید غیرقابل اطمینان باشد تا از عدم متناقض سیستم جلوگیری شود.

همه داده های تحت تأثیر عملیاتی که سازگاری نهایی را انجام می دهد ممکن است در یک بانک اطلاعاتی برگزار شود. در یک محیط معماری خدمات محور (SOA) ، یک عملیات می تواند یک عمل را در یک سرویس فراخوانی کند و باعث تغییر در ایالت شود که توسط آن سرویس برگزار می شود. برای خنثی کردن عملیات ، این تغییر دولت نیز باید خنثی شود. این فرآیند می تواند مستلزم فراخوانی دوباره سرویس و انجام یک عمل دیگر باشد که اثرات اول را معکوس می کند.

راه حل

راه حل اجرای یک معامله جبران کننده است. مراحل در یک معامله جبران کننده باید اثرات مراحل موجود در عملیات اصلی را خنثی کند. یک معامله جبران کننده ممکن است نتواند به سادگی وضعیت فعلی را با وضعیتی که سیستم در آغاز عملیات در آن قرار دارد جایگزین کند زیرا این رویکرد می تواند تغییرات ایجاد شده توسط سایر موارد همزمان یک برنامه را بازنویسی کند. در عوض ، این باید یک فرایند هوشمندانه باشد که هر کاری را که توسط نمونه های همزمان انجام می شود ، در نظر می گیرد. این فرآیند معمولاً خاص کاربردی خواهد بود که به دلیل ماهیت کار انجام شده توسط عملیات اصلی هدایت می شود.

یک رویکرد مشترک استفاده از یک گردش کار برای اجرای یک عملیات در نهایت سازگار است که نیاز به جبران خسارت دارد. با ادامه عملیات اصلی ، سیستم اطلاعات مربوط به هر مرحله و نحوه انجام کار توسط آن مرحله را می توان از بین برد. اگر این عملیات در هر نقطه ای انجام شود ، گردش کار از طریق مراحل انجام شده به عقب برگشته و کارهایی را انجام می دهد که هر مرحله را معکوس می کند. توجه داشته باشید که یک معامله جبران کننده ممکن است نیازی به خنثی کردن کار به ترتیب معکوس دقیق عملیات اصلی نباشد ، و ممکن است انجام برخی از مراحل خنثیسازی به صورت موازی امکان پذیر باشد.

این رویکرد مشابه استراتژی ساگاس است که در وبلاگ Clemens Vasters مورد بحث قرار گرفته است.

معامله جبران کننده نیز یک عملیات در نهایت سازگار است و همچنین می تواند شکست بخورد. سیستم باید بتواند معامله جبران کننده را در نقطه شکست از سر بگیرد و ادامه یابد. ممکن است لازم باشد یک مرحله که شکست خورده است تکرار شود ، بنابراین مراحل در یک معامله جبران کننده باید به عنوان دستورات idempotent تعریف شود. برای اطلاعات بیشتر ، به الگوهای IdemPotency در وبلاگ جاناتان الیور مراجعه کنید.

در بعضی موارد ممکن است بازیابی از مرحله ای که شکست خورده است به جز از طریق مداخله دستی امکان پذیر نیست. در این مواقع ، سیستم باید هشدار را جمع کند و تا آنجا که ممکن است اطلاعات مربوط به دلیل عدم موفقیت را ارائه دهد.

موضوعات و ملاحظات

هنگام تصمیم گیری در مورد نحوه اجرای این الگوی ، نکات زیر را در نظر بگیرید:

ممکن است مشخص نشود که چه زمانی یک مرحله در عملیاتی که سازگاری نهایی را اجرا می کند ، انجام نشده است. یک قدم ممکن است بلافاصله شکست بخورد ، اما در عوض می تواند مسدود شود. ممکن است لازم باشد نوعی مکانیسم زمان را اجرا کند.

منطق جبران خسارت به راحتی تعمیم نمی یابد. معامله جبران کننده خاص برنامه است. این برنامه به برنامه دارای اطلاعات کافی متکی است تا بتواند اثرات هر مرحله را در یک عملیات شکست خورده خنثی کند.

مراحل را در یک معامله جبران کننده به عنوان دستورات idempotent تعریف کنید. در صورت عدم موفقیت معامله ، مراحل را می توان تکرار کرد.

زیرساخت هایی که مراحل موجود در عملیات اصلی را انجام می دهد و معامله جبران کننده باید انعطاف پذیر باشد. نباید اطلاعات مورد نیاز برای جبران یک مرحله ناکام را از دست بدهد ، و باید بتواند با اطمینان نظارت بر پیشرفت منطق جبران خسارت باشد.

یک معامله جبران کننده لزوماً داده های موجود در سیستم را به وضعیتی که در آغاز عملیات اصلی در آن بوده است ، باز نمی گرداند. درعوض ، این کار را با مراحل انجام شده با موفقیت قبل از عدم موفقیت عمل ، جبران می کند.

ترتیب مراحل در معامله جبران کننده لزوماً برعکس مراحل موجود در عملیات اصلی نیست. به عنوان مثال ، یک فروشگاه داده ممکن است نسبت به ناسازگاری نسبت به دیگری حساس تر باشد ، بنابراین مراحل مربوط به معامله جبران کننده که ابتدا تغییرات در این فروشگاه را خنثیسازی می کند ، باید در ابتدا اتفاق بیفتد.

قرار دادن یک قفل مبتنی بر زمان کوتاه مدت بر روی هر منبعی که برای انجام یک عملیات لازم است و به دست آوردن این منابع از قبل ، می تواند به افزایش احتمال موفقیت در فعالیت کمک کند. کار باید فقط پس از دستیابی به تمام منابع انجام شود. قبل از پایان قفل ها باید تمام اقدامات نهایی شود.

برای به حداقل رساندن خرابی هایی که باعث ایجاد معامله جبران کننده می شود ، استفاده از منطق آزمایش مجدد را که بخشنده تر از حد معمول است ، در نظر بگیرید. اگر گامی در عملیاتی که سازگاری نهایی را انجام می دهد ، شکست بخورد ، سعی کنید شکست را به عنوان یک استثناء گذرا انجام دهید و مرحله را تکرار کنید. اگر یک قدم به طور مکرر انجام شود یا نتواند بازیابی شود ، فقط عملیات را متوقف کرده و معامله جبران کننده را آغاز کنید.

بسیاری از چالش های اجرای یک معامله جبران کننده همان مواردی است که با اجرای قوام نهایی. برای اطلاعات بیشتر ، به بخش ملاحظات مربوط به اجرای سازگاری نهایی در آغازگر سازگاری داده مراجعه کنید.

چه موقع از این الگوی استفاده کنید

از این الگوی فقط برای عملیاتی استفاده کنید که در صورت عدم موفقیت باید از بین بروند. در صورت امکان ، راه حل های طراحی برای جلوگیری از پیچیدگی نیاز به جبران معاملات.

مثال

یک وب سایت مسافرتی به مشتریان امکان می دهد برنامه های سفر را رزرو کنند. یک برنامه سفر ممکن است شامل یک سری پرواز و هتل باشد. مشتری که از سیاتل به لندن سفر می کند و سپس به پاریس می تواند مراحل زیر را هنگام ایجاد برنامه سفر انجام دهد:

1. یک صندلی را در پرواز F1 از سیاتل به لندن رزرو کنید.
2. یک صندلی در پرواز F2 از لندن به پاریس رزرو کنید.
3. یک صندلی را در پرواز F3 از پاریس به سیاتل رزرو کنید.
4. یک اتاق در هتل H1 در لندن رزرو کنید.
5. یک اتاق در هتل H2 در پاریس رزرو کنید.

این مراحل یک عملیات در نهایت سازگار است ، اگرچه هر مرحله یک عمل جداگانه است. بنابراین ، علاوه بر انجام این مراحل ، سیستم همچنین باید در صورت تصمیم گیری مشتری برای لغو برنامه سفر ، عملیات ضد لازم را برای خنثیسازی هر مرحله ثبت کند. مراحل لازم برای انجام عملیات پیشخوان می تواند به عنوان یک معامله جبران کننده اجرا شود.

توجه کنید که مراحل معامله جبران کننده ممکن است برعکس مراحل اصلی نباشد و منطق در هر مرحله در معامله جبران کننده باید هرگونه قوانین خاص تجاری را در نظر بگیرد. به عنوان مثال ، بدون رزرو یک صندلی در پرواز ممکن است به مشتری حق بازپرداخت کامل هر پولی را پرداخت کند. این شکل نشان دهنده ایجاد یک معامله جبران کننده برای خنثی کردن یک معامله طولانی مدت برای رزرو برنامه سفر سفر است.

بسته به نحوه طراحی منطق جبران کننده برای هر مرحله ، ممکن است مراحل موجود در معامله جبران کننده به صورت موازی انجام شود.

در بسیاری از راه حل های تجاری ، عدم موفقیت یک مرحله همیشه نیازی به عقب نشینی سیستم با استفاده از یک معامله جبران کننده ندارد. به عنوان مثال ، اگر - پس از رزرو پرواز F1 ، F2 و F3 در سناریوی وب سایت سفر - مشتری قادر به رزرو اتاق در هتل H1 نیست ، ترجیح می دهد یک اتاق را در یک هتل متفاوت در همان شهر ارائه دهد. از لغو پروازها. مشتری هنوز هم می تواند تصمیم به لغو (در این صورت معامله جبران کننده انجام دهد و رزروهای انجام شده در پروازهای F1 ، F2 و F3 را خنثی کند) ، اما این تصمیم باید توسط مشتری و نه توسط سیستم انجام شود.

منابع مرتبط

الگوهای و راهنمایی های زیر نیز ممکن است هنگام اجرای این الگوی مرتبط باشد:

آغازگر سازگاری داده. الگوی جبران خسارت اغلب برای خنثی کردن عملیاتی که مدل سازگاری نهایی را اجرا می کنند ، استفاده می شود. این آغازگر اطلاعاتی در مورد مزایا و مبادلات قوام نهایی ارائه می دهد.

الگوی برنامه ریزی کننده-آژانس-سرپرست. نحوه اجرای سیستم های انعطاف پذیر که عملیات تجاری را که از خدمات و منابع توزیع شده استفاده می کنند ، توصیف می کند. بعضی اوقات ، ممکن است لازم باشد کار انجام شده توسط یک عملیات با استفاده از یک معامله جبران کننده انجام شود.

الگوی آزمایش مجدد. جبران معاملات می تواند گران باشد ، و ممکن است با اجرای یک سیاست مؤثر در تلاش برای انجام عملیات ناکام با پیروی از الگوی آزمایش مجدد ، استفاده از آنها را به حداقل برساند.